Send an action to the payment provider [adapter]
The Bango Platform uses this endpoint to send an action to a payment provider, or an adapter for a payment provider.
The available actions constitute a small fixed vocabulary for communications initiated by the Bango Platform. An action can:
- Ask the payment provider [adapter] to perform an operation
- Request data from the payment provider [adapter]
- Notify the payment provider [adapter] of an event of interest
Every action sent (a request action) may result in a range of possible responses (response actions) from the payment provider [adapter]. Each request action defines the expected response actions.
Every request action will include a unique id property (UUID v4). This identifies the request action and is not used for any other purpose (it’s not a payment resource ID, for example). The response action corresponding to the request action must include the request action’s id.
HTTP responses
The Bango Platform always sends a request to the payment provider [adapter] over HTTP, and the payment provider [adapter] must return an HTTP response. HTTP requests contain request actions as defined in this specification.
The HTTP response MUST be one of the following:
- HTTP 204 NO CONTENT - permitted only if the request needs a simple acknowledgement without specific response data
- HTTP 200 OK - containing a response action in the response body. Each request action defines the expected response actions
- HTTP 4xx - indicating a problem with the request action
- HTTP 5xx - indicating a problem with the payment provider [adapter] system
This specification defines the shape of HTTP 4xx and 5xx responses. These all have a response body containing an errors array, each member of which is an object containing an error code and other data.
If a request to a payment provider [adapter] times out, this is treated the same as an HTTP 503 error from the payment provider [adapter] with canRetry: true.
HTTP 400 BAD REQUEST responses
For HTTP 400 BAD REQUEST responses specifically, the payment provider [adapter] MUST use these values for code for the error conditions listed:
invalid-json- If the request body isn’t valid JSON format
missing-parameter- If any required parameter is not present in the request body. For example,
id,type,payload, or any required value insidepayload.
- If any required parameter is not present in the request body. For example,
invalid-parameter- If any parameter in the request is syntactically invalid. For example, if
typeis an integer, or ifidis not a UUID v4 - If any parameter in the request is semantically invalid. For example, if a
payloadfield specifies a user identifier and that user isn’t recognized by the payment provider [adapter]
- If any parameter in the request is syntactically invalid. For example, if
The payment provider [adapter] MAY use other values of code for an HTTP 400 BAD REQUEST response with other error conditions. The specification for each request action defines the additional permitted values of code.
HTTP 5xx responses
HTTP 5xx responses indicate a problem with the payment provider [adapter]. This might be a temporary problem caused by a network issue between the Bango Platform and the payment provider [adapter], or it may indicate a more serious, persistent issue.
Any 5xx response from the payment provider [adapter] propagates through the platform as a service error with code payment-provider-failure. The 5xx response from the payment provider [adapter] may specify that the request can be retried, using the meta.canRetry boolean in the 5xx response.
A timeout in the connection from the Bango Platform to the payment provider [adapter] is always reported as a payment-provider-failure that may be retried.
Authorizations
Basic authentication header of the form Basic <encoded-value>, where <encoded-value> is the base64-encoded string username:password.
Headers
The value of type from the request body, indicating the type of request action. Allows payment providers [adapters] to route request actions without inspecting the request body.
NOTIFY_SESSION_FLOW, AUTHORIZE, CAPTURE, REFUND, CANCEL_AUTH, CHARGE, GET_ELIGIBILITY, SEND_MT_MESSAGE, VALIDATE_PASSPHRASE, SEND_OTP, VERIFY_OTP Body
An action initiated by the Bango Platform, to be processed by the payment provider [adapter].
The following action types are available. See each action type schema for detailed information on purpose and response action types.
NOTIFY_SESSION_FLOW: Tell the payment provider [adapter] that a merchant partner is starting an identity verification flowAUTHORIZE: Ask the payment provider [adapter] for payment authorization: the first step in a two-step (Authorize/Capture) payments model.CAPTURE: Ask the payment provider [adapter] for payment capture: the second step in a two-step (Authorize/Capture) payments modelREFUND: Ask the payment provider [adapter] to charge a payment request: one-step payments modelCANCEL_AUTH: Ask the payment provider [adapter] to cancel an authorization on a payment request.GET_ELIGIBILITY: Ask the payment provider [adapter] for up-to-date eligibility data for an end userSEND_MT_MESSAGE: Ask the payment provider [adapter] to send a message to a particular end user deviceVALIDATE_PASSPHRASE: Ask the payment provider [adapter] to validate a passphrase to a particular end user deviceSEND_OTP: Ask the payment provider [adapter] to send an OTP to a particular end user deviceVERIFY_OTP: Ask the payment provider [adapter] to verify an OTP provided by the merchant end userCHARGE: Ask the payment provider [adapter] to charge a payment request: one-step payments model
- AUTHORIZE request action (outbound)
- CANCEL_AUTH request action (outbound)
- CAPTURE request action (outbound)
- CHARGE request action (outbound) [plan-p1]
- REFUND request action (outbound)
- GET_ELIGIBILITY request action (outbound)
- NOTIFY_SESSION_FLOW request action (outbound)
- SEND_MT_MESSAGE request action (outbound)
- VALIDATE_PASSPHRASE request action (outbound)
- SEND_OTP request action (outbound)
- VERIFY_OTP request action (outbound)
Ask the payment provider [adapter] for payment authorization: the first step in a two-step (Authorize/Capture) payments model. This step reserves funds against the end user's payment instrument with the payment provider.
How it works: merchant partners send an AUTHORIZE action for a payment resource. Route policy determines whether authorization is permitted. If so, OPPA will send an AUTHORIZE action to the payment provider [adapter].
The payment provider [adapter] responds either to approve or deny authorization (or signal an error in the request).
Supported HTTP responses
- HTTP 200 OK:
AUTHORIZE_APPROVED_RESPONSEresponse actionAUTHORIZE_DENIED_RESPONSEresponse action
- HTTP 204 NO CONTENT:
- Simple acknowledgement approving authorization, without additional data
- HTTP 400 BAD REQUEST with one or more errors:
code==invalid-json:- the request body is not valid JSON
code==missing-parameter:- a required parameter is omitted from the request action
code==invalid-parameter:- a parameter is not of the expected type, or
- a parameter violates the documented constraints
A unique identifier for the request action (not used for any other purpose). If the recipient of the request action returns a response action, the response action must specify the same identifier as its own id.
"2adf1639-bb50-4df7-b8a0-79a0cd4f2277"
Properties related to idempotency, to help with reconciliation between the Bango Platform and the payment provider.
Omitted if the merchant partner did not specify an Idempotency-Key with the request.
Response
The response action, which depends on the request action.
- GET_ELIGIBILITY_RESPONSE response action
- AUTHORIZE_APPROVED_RESPONSE response action
- AUTHORIZE_DENIED_RESPONSE response action
- CANCEL_AUTH_APPROVED_RESPONSE response action
- CANCEL_AUTH_DENIED_RESPONSE response action
- CAPTURE_APPROVED_RESPONSE response action
- CAPTURE_DENIED_RESPONSE response action
- CHARGE_APPROVED_RESPONSE response action [plan-p1]
- CHARGE_DENIED_RESPONSE response action [plan-p1]
- REFUND_APPROVED_RESPONSE response action
- REFUND_DENIED_RESPONSE response action
- NOTIFY_SESSION_FLOW_APPROVED_RESPONSE response action
- NOTIFY_SESSION_FLOW_DENIED_RESPONSE response action
- SEND_MT_MESSAGE_RESPONSE response action
- VALIDATE_PASSPHRASE_RESPONSE response action
- SEND_OTP_RESPONSE response action
- VERIFY_OTP_RESPONSE response action
Response to a GET_ELIGIBILITY action. Contains information about the current eligibility of an end user.

